Skip to content

Parse supportedOperations into Resource #28

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 5 commits into from
Apr 6, 2018
Merged

Parse supportedOperations into Resource #28

merged 5 commits into from
Apr 6, 2018

Conversation

olivermack
Copy link

Hey,

as a user of this lib which consumes an api-platform hydra documentation I'd like to see the contents of the supportedOperation entries reflected inside the Resource objects which are generated by the parseHydraDocumentation.

Background: I've tweaked my API to provide context-sensitive documentation based on the user's privileges - thus, the supportedOperation entries are only visible in the api doc when the user is allowed to call that endpoint. To be honest, I did not get very deep into hydra but I hope there's no conceptual violation by using the supportedOperation in a context-sensitive manner. I'm pretty aware though that the hydra-documentation can be outdated or a state supportedOperation on documentation-read can become unsupported when the user invokes it some moments later.

Why: I want to adjust my SPA in such a way that turns on/off certain functionalities based on those supportedOperations - basically using them as permission based feature flags.

What I did not implement yet is an according parsing of the hydra:supportedClass#Entrypoint specs.

Best

@olivermack
Copy link
Author

olivermack commented Mar 4, 2018 •
edited
Loading

Can anyone tell me why the hydra:writable property is false in such entrypoint specifications where a POST (write) operation exists?

api-doc-parser/src/hydra/parseHydraDocumentation.test.js

Line 370 in 3d5d9dc

"hydra:writable": false

I also came already across this in the DocumentationNormalizer of the PHP library - the readable and writable properties and their values are hardcoded but I don't know why. At the end it seems a bit counter intuitive to me - if there's a POST supported operation on an Entrypoint then it is writable, isn't it?

Best

@omack
Collecting all operations
773051c 
Collecting entrypoint operations and inject them into the resource's operations as well
@olivermack olivermack changed the title [WIP] Parse supportedOperations into Resource Parse supportedOperations into Resource Mar 5, 2018
@olivermack
Copy link
Author

olivermack commented Mar 5, 2018 •
edited
Loading

Actually I wanted to add references to other resources here as well, e.g. for the return values - maybe this could be an extension of the last state.

There are some unknowns which I did not handle explicitly because I don't know the reason for them:

  1. See comment above
  2. The GET entrypoint-spec for the book resource differs from the review spec. Where review describes range and hydra:supportedOperation, book describes rdfs:range and no hydra:supportedOperation. I don't know how to reflect that best.
  3. expects data is not handled - Implemented that... but it brought up two other things: for CustomResource there are two Creates a custom resource. defined, one in the entrypoint and the other one in the resource spec. And: DELETE operations do not specify any expects... Why is that?

Anyway, IMHO this is okay for now.

@olivermack
Copy link
Author

Is there anyone willing to give some feedback on this?

mauchede
mauchede approved these changes Apr 6, 2018
View reviewed changes
Copy link
Contributor

@mauchede mauchede left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK for me. @dunglas, what do you think?

@dunglas dunglas merged commit a0a2c37 into api-platform:master Apr 6, 2018
@dunglas
Copy link
Member

dunglas commented Apr 6, 2018

Thanks @olivermack

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mauchede mauchede mauchede approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@olivermack @dunglas @mauchede @omack